UX Cafe: チームで取り組む！サイボウズのアクセシビリティ
https://gyazo.com/b543e0ab9567483fc645b09659dc79db
チームワーク溢れる社会を創る
ユーザは製品にアクセスしたことで何にアクセスしようとしているのか？
チームにアクセスしたい
「ユーザがチームにアクセスできる能力」
小関 直子 Garoonチーム QA
Garronの紹介
中堅・大規模組織向けグループウェア
オンプレミス／クラウド
中央省庁での導入実績あり
アクセシビリティ対応の歴史
PC上のWeb画面
4年前→現在
ゴールが見えてきた
チームで試行錯誤していこう
チーム→アクセシビリティ・ギルド
活動
ゴールの設定
Garoonユーザがチームにアクセスできると自身持って言える
アクセシビリティ対応状況の宣言
時間を決めて活動
宿題にしない
1h/2w
WCAG2.0 読み合わせ
勉強会・ワークショップ
アクセシビリティチェックリスト
最低限のものを絞る
仮運用スタート
要件化へのアピール
製品価値向上に紐付ける
進め方
n%アクセシビリティ要件をつめていこうとおもったが
崩壊してしまった
やるべき要件にアクセシビリティを考慮していく
所感
１人はきびしい・仲間を作る
心が動くポイント
社会貢献・正義感
ビジョンとの関係性
製品価値向上
好奇心
試行錯誤
歩みを止めない
職能別活動紹介
デザイナー
チェックリスト
マウス／キーボード／タッチデバイスで操作できる
キーボード操作
スクリーンリーダーで情報が把握できる
色のみで情報を伝えない
コントラスト比の確保
200%拡大でも操作できるようにする
新デザイン化とアクセシビリティ
軸にアクセシビリティを入れる
ビジュアルの変更
アイコン
絵柄の考慮
png → svg（拡大考慮）
変更は進めやすい（ロジックはかかわらない）
プログラマー
操作可能で堅牢なUIを実装
Accesibleな動き・ステート管理
アクセシビリティ対応で工数の倍、実装にかかってしまった
キーボード対応
動きの仕様書
１つ１つ対応
予め仕様を把握しておくべきだった
シンプルなUIを追求
StateとView
State
プログラマ
View
デザイナー
分業となっていたので実装を意識してコミュニケーションを取りたかった
動作確認の難しさ
うまく動かない時になんの問題かわからない
NVDAとChromeで動くが
VoiceOverとSafariだと読み上げられないこともある
W3Cの実装例チェック
ブラウザ・支援技術の問題をはやめにキャッチ
割り切る！
テスト・QA業務
今までのアクセシビリティテスト
1. 準備
テスト前に実施したこと
汎用的なアクセシビリティ知識の共有
テストで使うツールの統一
2. テスト
機能テストの合間に実施
気付きベース
3. 結果
読み上げで読み上げられない
拡大でレイアウトが崩れる
一部見づらい
タグ情報が記載されてない
タブ遷移ができない
4. 所感
機能テストの中でアクセシビリティチェック行けそう
早急な改修と見送りで振るいにかけられてしまった
ツールの仕様問題
他への影響がある場合
思ったよりも効果が薄かった
ギルド加入後
テスト対象
やみくもにやらず、機能要件単位で対象を絞る
テスターの主観に依存させない
チェックリストを活用
観点と内容を定義
WCAGの項目単位で作成
その対応がどのユーザーに価値があるか
どのように確認できるのか？
チェック対象外になる部分も明記
これからの方針
1. テスト前
チェックリストベースで共有
テスト観点の共通認識をもつ
ツールの実際の使われ方を共有
2. テスト
チェックリストベースのテスト
指摘ミスや観点のばらつき防止
検出すべきバグを検出すべきタイミングで
3. これから目指すもの
QAの誰もが、アクセシビリティテストの実績をつみ
テスト自体もアップデートしていけるように
トーク2: TCチームのアクセシビリティ
山本 絵理 TCチーム
近藤 有紀 TCチーム
Technical Communication
マニュアル制作
製品文言制定
多言語対応の場合、翻訳対応
ライティング担当が書いたらコーダー担当がWeb対応する
サイボウズ Office
ヘルプサイト
アクセシビリティ対応している
きっかけ
勉強会で知った・衝撃をうける
ピンク本読書会
ヘルプこそアクセシビリティが大事
マニュアルに取り入れてみようと思った
チャンス
リニューアルするときが一番良い
製品とマニュアルは連動
現状を分析
Google Analytics
モバイルのセッション増加
当時レスポンシブ未対応だった
トップページの直帰率悪い
検索性が悪いからではないか
検索性（探しやすさ）を回答する割合が多い
ユーザーアンケート
スマートフォン対応を希望
わからない場合はマニュアル、FAQを調べる回答
やりたいことを実現するのがアクセシビリティが最適解
PMに説明
コンセプト
状況や環境に左右されないサイト設計
何をやるか
WCAG基準リストアプリをつくった
本家はみづらかった
達成基準ごとで検索
スタイルガイドをアクセシビリティ項目追加
スタイルガイドは元からあった
見やすく・理解しやすく
デザインとマークアップ
HTMLをきれいに
セマンティクス
文字
製品に併せてフォントを合わせるべき？
歴史のある製品なので、どうしても変わらないところがある
企業サイトがリニューアル
こちらを参考にしてみた
キーボード対応
ここは操作できる、ここは操作できないはなくす
他チームの存在
アクセシビリティ対応したチームがスレッドを立てて発信
当時神々の投稿と呼んでいた
2300ページのリライトと7000枚の画像のalt対応を1人でやった
色の調整は先にやる
後々でバッティングしかねない（イタチごっこになりかねない）
あちらも直すとこちらも直す
アクセシビリティに終わりはない
ルール制定、取り入れたコードはテンプレ化
まだ一部しか対応できていない
いままでやってきた施策
チェックリスト
ごく簡単なリスト
A4で収まるくらい
デザイン
実装
できたこと
基本的なカタログ・リファレンスとして使った
できなかったこと
上流で活用されない（要件定義の段階）
対応の度合いがまちまち
複雑なUIで対応できなかった
成果物のレビュー会
うまくできたところ・できなかったところを共有
できたこと
アクセシビリティ対応の足りないことが理解された
チェックリストの参照が増えた
できなかったこと
修正コストが高くて直せない
開催コストが高くて期間があく
書籍の論考
有識者の講演会
当事者をふくめたワークショップ
アクセシビリティは大切、でも…
特別視しない
日常的に議論しよう
Try1:ユーザビリティテスト
ロービジョンの人にも参加
利点
要件定義やデザイン担当するメンバーに観察してもらえた
デザインも改善できた
Try2: モブデザイン・プログラミング
最近のサイボウズの開発スタイル
よりよいHTML／CSSを考える
その場でWAI-ARIAを伝える
VoiceOverを起動して読み上げを聞いてもらう
利点
修正コストが低くなる
知見共有できる
レビューとくらべてコストがかからない
Try3: プランニングで議論
要件を実装するにあたり懸念点や考慮すべきことを議論する会議がある
例：モバイルサイドベニュー実装
アニメーションをCSSでそうするか
コンポーネントはどう構成するか
VoiceOverで適切に読み上げてもらおう
利点
知見を共有できる
対応方針を具体的に議論できる
もともとある会議体に参加するだけでアクセシビリティ啓蒙
まとめ
今ある開発プロセスでアクセシビリティを日常化しよう